Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
User interfaces establishing application sessions on servers through a network may benefit from obtaining progress indicators related to tasks running in those sessions. But accessing available progress indicators is often unsatisfactory. Existing applications, which may already have progress indicator technology that runs beneath the application, must commonly re-implement the progress indicator function because the existing implementation is not compatible with a particular user interface (UI) technology. That is, the UI is expecting a certain type of response from the application and, as a result, the UI does not accept the progress indicator because it is not the expected type.
In addition, the available method of transferring progress information to a UI agent for the UI is based on polling technology. Polling-based progress indicators may lead to unnecessary network traffic and system load because the UI typically performs polling more often than the creation of new progress information by the application. Thus, in most cases, the UI does not receive any new progress information.
Polling technology issues also depend on the shared area used by the UI and the application. If the shared area is based on an application server assigned component, e.g., shared memory, polling may be an acceptable choice from the performance and resource consumption point of view, but load balancing must be disabled because load-balanced stateless requests do not work with such a shared area. On the other hand, using database tables as the shared area may address the load balancing issue, but may also lead to increased load and resource consumption on both the application and database servers.